fix(wait_event): drain signals with a blocking Receive loop (EN-1223) - #186
fix(wait_event): drain signals with a blocking Receive loop (EN-1223)#186flemzord wants to merge 1 commit into
Conversation
RunWaitEvent called channel.ReceiveAsync inside a workflow.Await predicate. An Await predicate is only evaluated once per workflow-task wakeup, so if a non-matching signal and the matching signal were delivered in the same workflow task, the predicate consumed the non-matching one, returned false, and the matching signal stayed buffered with nothing left to re-wake the coroutine -- blocking the stage forever. Non-matching events were also silently destroyed. Replace it with the canonical blocking Receive loop that drains signals one at a time until the expected event arrives. Adds a regression test signaling a non-matching then matching event in the same task.
|
Warning Review limit reached
More reviews will be available in 22 minutes and 46 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Superseded by #199, which consolidates this change with the related reliability and safety fixes on top of the current main branch. |
Problem (H3 — HIGH)
RunWaitEventcalledchannel.ReceiveAsyncinside aworkflow.Awaitpredicate:An
Awaitpredicate is evaluated only once per workflow-task wakeup. If a non-matching signal and the matching signal arrive in the same workflow task, the predicate consumes the non-matching one, returnsfalse, and the matching signal stays buffered with nothing left to re-wake the coroutine — the stage blocks forever. Non-matching events are also silently destroyed.Fix
Canonical blocking
Receiveloop that drains signals one at a time until the expected event arrives:Test
Adds a
TestWaitEventcase signaling a non-matching event then the matching one in the same task; the stage completes (it would hang under the old implementation).Severity: HIGH.